1. Field
The present disclosure relates to a system and a method of operating a printing system for parallel processing of a print job with a plurality of Raster Image Processors (RIPs) into a printer-ready format for the printing of the print job.
2. Description of Related Art
Generating print-ready documents to be printed by the printing system requires acquiring all the information (e.g., content, graphics, production specifications, etc.) required to view, process and output the desired document in an electronic format understandable by a print engine. Such systems range from those that are simple and modestly expensive, such as are well known to consumer users of personal computer systems, up to commercial printing systems that are capable of generating in the range of one thousand pages per minute in full color. All systems though have a high level objective of printing faster.
The process of converting information in the form of graphics, fonts and character placement information, and pictorial image content into a print-ready form, generally a raster image, possibly compressed or encoded in some way, is commonly known as Raster Image Processing (RIPping), and performed by what is called a Raster Image Processor (RIP). In any printing system, the speed is limited by the speed of the printer itself, (which is independent of the document complexity), and the speed of the RIP (which generally depends on the document, and may also depend on properties of the printer, such as its resolution, and its ability to support color), whichever is slower. The present application includes an embodiment that is directed at accelerating the RIP.
There are three general approaches that have been applied in the past for accomplishing the objective of printing faster. First, faster serial processing methods suggest optimizing the software and using faster and more expensive processors. Second, job parallel processing sends separate jobs to separate systems and then prints them on a common printer. Third, Portable Document Format (“PDF”) based page parallel systems convert the job to PDF, and then split the PDF file into pages which are converted to print-ready format on multiple independent processors, with the job being printed on a common printer.
Software optimization has its limitations and faster processors are also limited by currently available technology. Job parallel processing results in poor single job performance, unpredictable job time and reduced throughput when there is only one long job in the queue. The existing PDF-based solutions are slow due to their need to often convert from a different input language into PDF and then write the PDF file into an input spool disk. Page parallel processing has suffered from the inefficiencies of a throughput disadvantage because per job overhead occurs on a per page basis.
Accordingly, in the continuing need for improving efficiency and speed in printing systems, there is a need for a system which is not limited to mere job parallelism or page parallelism and that facilitates control and data flow of a print job to the printing system while splitting the print job into a plurality of print job portions, each of which is processed independently and in parallel. The splitting operation is generally performed by a splitter in the printing system. How a print job can be better split while ensuring page parallelism or chunk parallelism is a subject of this present disclosure.
Presently used splitters either operate on documents in a PDF format or rely on conformance to Document Structuring Conventions (DSC) to split.
Documents that do not conform to the DSC comments (e.g., the majority of Variable Data Intelligent Postscript Printware (VIPP) documents, and a minority of PostScript documents) either may be converted to PDF in order to be split or must be processed in serial. For example, some jobs that lack the DSC comments are currently processed in serial, and therefore such jobs are slow to print. In some printing systems, the speed ratio between serial and parallel processing could be a factor of 20-40, or even higher.
Among the documents that do not conform to the DSC comments are a majority of Variable Data Intelligent Postscript Printware (VIPP) documents. VIPP database mode is one of three modes of VIPP. Many, but not all, VIPP jobs use this mode, in which a small file containing a small amount of preamble information, and a series of records, typically small, is used along with PostScript procedures to construct the page content using additional files as a database. VIPP is a collection of PostScript procedures, which induce the PostScript interpreter to not only convert page descriptions to print-ready format but also create those page descriptions from a simple set of instructions along with a database. One record typically corresponds to one document to be sent to one customer. It could be the information needed to construct one billing statement, or it could be the information needed to construct a personalized catalogue. The currently used parallel Raster Image Processor (RIP) system splits VIPP database mode jobs at record boundaries. Normally records correspond to only a few pages, but they may run into hundreds of pages. Jobs may not be optimally split at record boundaries, especially in the case where records run into many pages. For this reason, and because other modes of VIPP are not amenable to splitting in this fashion, a splitter that understands PostScript is to be desired.
In the current parallel RIP system, a PostScript document is split by relying on the DSC comments. As a complete programming language (i.e., rather than a description language), Postscript includes variables, loops and many other common programming language structures. One problem that is often encountered is renaming of actual Postscript commands and/or the substitution of one action/command by another. This operator overload may be used for efficiency (as in VIPP jobs), for brevity, for simply replacing many commands with a single one, or for any other reason (e.g., obfuscation). A disadvantage of this is that no processing of the Postscript data may be done without actually executing the entire program, which is a time-consuming process. Applicants of the present disclosure, in one embodiment, propose a method and system to execute the program without performing the action/commands so as to circumvent the operator overload while maintaining efficiency.